This only works if gtsam is pulled via FetchContent or similar. If it's installed instead, and the macro is used at the top-level, it won't work.

Good catch, and you're right about the boundary. The top-level check (CMAKE_PROJECT_NAME STREQUAL PROJECT_NAME) only covers the case where gtsam is built in-tree as a subproject (FetchContent / add_subdirectory), which is exactly the #2401 repro: the consumer's build pulls gtsam in and gtsam's own targets get -Werror and fail under a newer compiler.

Two cases I want to separate:

1. Installed gtsam consumed the normal way (find_package(GTSAM) + target_link_libraries(app gtsam)): -Werror lives in GTSAM_COMPILE_OPTIONS_PRIVATE_COMMON and is applied PRIVATE in gtsam_apply_build_flags, so it's never in the exported INTERFACE. Those consumers were already unaffected.
2. Installed gtsam where the downstream calls gtsam_apply_build_flags() on its own target at its top level: here CMAKE_PROJECT_NAME == PROJECT_NAME is the downstream's name, the option defaults ON, and -Werror lands on the downstream target. That's the hole, the project-name heuristic is the wrong axis for that path.

Is (2) the scenario you have in mind? If so, I think the cleaner fix is to stop keying off "am I the top-level project" and only enable -Werror when flags are applied to gtsam's own targets (gate it inside gtsam_apply_build_flags on a gtsam-owned-target check), so reusing the macro downstream never re-enables it. Happy to rework it that way, just want to confirm that's the path you'd want before I redo the gating.

That is the scenario I'm thinking of, although I'm not sure if gating it is the right solution, since I'm not really sure what the use cases are for the gtsam_apply_build_flags macro. Ultimately, I'm really curious as to why a downstream consumer is reusing that macro, since that feels a little strange to me (I'd typically just apply the flags independently), and I'd like to know if that's actually a supported use case. If it is, then gating it behind a "Is gtsam project" check is probably fine.